Reverted: use optimised ByteString.asInputStream #539
Conversation
pjfanning
commented
Apr 19, 2024
•
pjfanning
commented
- ByteString.asInputStream is only in Pekko 1.1 - so if you use this code with Pekko 1.0, the MethodHandle will not work and the code falls back to existing ByteArrayInputStream
pjfanning
force-pushed
the
bytestring-opt
branch
from
b95c28f
to
246f4f8
Compare
|
I benchmarked this using https://github.com/pjfanning/pekko-test/blob/main/bench/src/main/scala/org/example/pekko/ByteStringBench.scala The new code (in this PR) was faster for byte strings that are made up of multiple byte strings but slower for simple byte strings. While the speedup for complex byte strings is good and the slowdown for simple byte strings is proportionally small - it might not be worth the hit. I presume that the MethodHandle adds an overhead. |
|
Now have after pjfanning/pekko-test@a79e14f |
pjfanning
changed the title
Update Http2FrameHpackSupport.scala Update ByteStringInputStream.scala revert Http2FrameHpackSupport change Update ByteStringInputStream.scala Update ByteStringInputStream.scala
pjfanning
force-pushed
the
bytestring-opt
branch
from
4304c5f
to
ab57232
Compare
| val lookup = MethodHandles.publicLookup() | ||
| val inputStreamMethodType = MethodType.methodType(classOf[InputStream]) | ||
| lookup.findVirtual(classOf[ByteString], "asInputStream", inputStreamMethodType) | ||
| }.toOption |
There was a problem hiding this comment.
- I think we should drop the
lazyand just make it aval. - the
toOptionwill introduce an allocation, useOptionVal
There was a problem hiding this comment.
this code is only called once in the whole lifetime of the JVM
There was a problem hiding this comment.
I think it should be lazy because this code may need to run unless it is needed
There was a problem hiding this comment.
But the lazy will introduce a volatile iirc, I think this is a trade-off, just not sure if that will cause the problem in the native image.
There was a problem hiding this comment.
OptionVal does not support changing a Try[A] to an Option[A]. So OptionVal does not look a viable approach here.
There was a problem hiding this comment.
The getorelse will introduce another closure creation, think we can just fallback to imperative style for performance reason
There was a problem hiding this comment.
I found that the getOrElse has a small cost so I made a change to remove it
...ore/src/main/scala/org/apache/pekko/http/impl/engine/http2/hpack/ByteStringInputStream.scala
Outdated
Show resolved
Hide resolved
Update ByteStringInputStream.scala Update ByteStringInputStream.scala
pjfanning
force-pushed
the
bytestring-opt
branch
from
ab57232
to
253e3d8
Compare
|
LGTM |
This reverts commit 03f1289.
This reverts commit 03f1289.
pjfanning
changed the title
